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SECTION 
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SECTION 



ftn , GENERAL 
802 X TEXT 

SECTION 



simple.html 



<!- This is a Simple Template File. 
Its purpose is to to show the difference 
between General Text 
and Template Sections -> 

<!- A General Text Section begins here -> 
<HTML> 

<!- Put the DN in the Title -> 

<TITLE>%DN%<mTLE> 

<BODY> 

<!- display the friendly name for "ou" 

|and the organizationalUnit name -> 
%ATTR NAME="ou"%: %VAL NAME="ou"%<BR><BR> 
<!- A General Text ends here -> 

<!- A Template Section begins here -> 

%TEM PLATE OC="pilotPerson"% 

<B> The following People were found:</B><BR> 

%LOOP% 

%LINK%%valNAME="cn"%%/UNK%<BR> 

%/LOOP% 

%/TEMPLATE% 

<!- A Template Section ends here -> 

<!- A General Text begins here -> 
<BR> 

%UPLEVEL% Go UP To Previous Level %/UPLEVEL% 

<BR> 

</BODY> 

</HTML> 

<!- A General Text ends here -> 
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<HTML> 

<TITLE>%DN%</TITLE> 
<B0DY> ^2 
<PRE> 
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%ATTR NAME="ou"%: <A HREF="%DN%?">%val name=W%</A> 

910 ~lW^ME="sa7o: %VALNAME=V% ^4 

916 %ATTRNAME=T%: %VALNAME=T% 918 

920 — ' ^ 

%AnRNAME="sopn"%: %VAL NAME="sopn"% 922 

h %/TEMPLATE% ^ ^ 

</PRE> 

%UPLEVEL%UP to XYZCorp%/UPLEVEL% 



</B0DY> 930 
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<HTML> 

<TITLE>%DN%<TITLE> 
<B0DY> 10 02 
<PRE> 

%ATTR NAME="ou"%: %VAL NAME="ou"%<BR> 
%TEMPLATE OC= B pilotPerson"% ^ Q6 
Staff: 10O8 

%L00P% ^$ 18 

1012-^%AnRNAME="cn"%: %LINK%%VAL NAME='cn"% %/LINK% 

1016- %AfTRNAME=T%: %VAL NAME=T%^„ 

v 1022 
%/L00P% ^4 1026 

%/TEMPLATE% 

1014 

</PRE> 1010 

%UPLEVEL%Up to XYZCorp%/UPLEVEL% ^ 1 030 
</BODY^~-1028 

</HTML> 
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<HTML> 

<TITTLE>%DN%<mTLE> 
<B0DY> ^2 

1104 

DN : <OL>%DNDELIMIT="<BR>"PRETEXT= , <STRONG>" 
06 P0STTEXT="</STR0NG>"%</0L> 

%ATTR NAME="ou"% : %VALNAME= , ou" PRETEXT="<STRONG>" -^" 110B 
POSnEXT="</STRONG>'%<BR><BR> 

<PRE> ™° y 



%ATTRNAME="sa"%: %VAL NAME="sa"% 



1116 

1114 — ^ / 
%ATTR NAME="1"%: %VALNAME=T% 



%ATTR NAME='sopn"%: %VAL NAME="sopn"% 

</PRE> 1122 \ \ 
^ \ 1118 1120 

%ATTRNAME="d"%: 

■<UL> %VALNAME="d" POSTTEXT="</LI>" PRETEXT="<LI>"% </UL> 

- %TEMPLATE OC= n pilolPerson"% 

<tabte align="top" border=T bgcolor="#00FFFF" 
bordercolor="#0000FF"> 

<td colspan = "3" align=W> 

<F0NT SIZE='3"><B>The staff : </B></td> 

</FONT> 

1130 ^%LOOP% A3* 

<tr align="lefT><td colspan=T>%LINK%%val NAME="cn'% 
%/LINK%</td> \ 

<tdalign="right" td colspan=T>%VAL NAME=T 1138 
1136 DELIMIT=","%</td> \ 
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%ATTR NAME="ou"%: %VAL NAME="ou"%<BR> 
s s 
1204 1206 
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<HTML><TITLE>Sales Staff Search</TITLE> 

<BODY>Welcome to the XYZCorp Sales Staff Search.<BR> 

Please enter the Common Name to search for. 1302 

<FORM METHOD=POST / 
ACTION= B ou%3dSALES%2co 0 /o3dXYZCorp%2cc%3dUS??(cnSF=SN) B > 

Common Name:<INPUT TYPE=TEXT NAME=param2 SIZE=32 
MAXLENGTH=2000><BR> 

<INPUTTYPE=CHECKBOX NAME=param1 VALUE= B -">Approximate 
match.<BR> 

<INPUT TYPE=SUBMIT VALUE="Search"> 

<INPUT TYPE=RESET VALUE="Reset"> 

</FORM> 

</BODY> 

</HTML> 



FIG. 13A 



03/29/2004, EAST version: 1.4.1 



U.S. Patent Feb. 20, 2001 Sheet 19 of 24 US 6,192,362 



<HTML><TITLE>Sales Staff Search<TITLE> 

<BODY>Welcome to the XYZCorp Sales Staff Search. <BR> 

Please enter the Common Name of the Staff Member you wish to 
search for. 1304 

<FORMMETHOD=POST , , 

ACTION= n ou%3dSALES%2co%3dXYZCorp%2cc%3dUS?? (&(cnSF=SN) (objec 
tClass=pilotPerson))"> 

Common Name:<INPUT TYPE=TEXT NAME=param2 SIZE=32 
MAXLENGTH=2000><BR> 

<1NPUT TYPE=CHECKBOX NAME=param1 VALUE="-">Approximate 
match.<BR> 

<INPUT TYPE=SUBMIT VALUE="Search"> 
<INPUT TYPE=RESET VALUE="Reset"> 
</FORM> 
</BODY> 
</HTML> 



FIG. 13B 
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Welcome to the XYZCorp Sales Staff Search. 
Please enter the Common Name to search for. 



Common Name: *Doe 



□ Approximate match 



Search Reset 



g#38> [Document: Done ZJl ) B? 
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<HTML><TITLE>Sales Unit Search</TITLE> 
<BODY>Welcome to the XYZCorp Sales Unit Search.<BR> 
Please enter the Common Name to search for. 
<FORM METHOD=POST 

ACTION="ou%3dSALES%2oo%3dXYZCorp%2cc%3dUS?? (& (cnSF=SN) (ST(ob 
jectClass=pilotPerson)))"> 

Common Name:<INPUTTYPE=TEXT NAME=param2 SIZE=32 
1402 MAXLENGTH=2000><BR> 

<INPUTTYPE=CHECKBOX NAME=param1 VALUE="-">Aproximate 
match.<BR> 

<INPUT TYPE=CHECKBOX NAME=param3 VALUE=T>Do not search for 
Staff members.<BR> 

<INPUT TYPE=SUBMIT VALUE="Search"> 
<INPUT TYPE=RESET VALUE="Reset"> 
</FORM> 
</BODY> 
</HTML> 
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<HTML><TITLE>Sales Unit Search</TITLE> 
<BODY>Welcome to the XYZCorp Sales Unit Search.<BR> 
Please enter the Common Name and Title to search for. 



<FORM METHOD=POST r 
ACTION= n ou%3dSALES%2co%3dXYZCorp%2cc%3dUS?? (SC(cnSF 
SN))"> 

You may search on <INPUT TYPE=RADIO CHECKED NAME=param1 
VALUE=T>Both or 

<INPUTTYPE=RADIO NAME=param1 VALUE="|">Either<BR> 

Common Name:<INPUT TYPE=TEXT NAME=param3 SIZE=32 
MAXLENGTH=2000><BR> 

<INPUT TYPE=CHECKBOX NAME=param2 VALUE="-">Aproximate 
match.<BR><BR> 

Title:<INPUT TYPE=TEXT NAME=param5 SIZE=32 
MAXLENGTH=2000><BR> 

<INPUTTYPE=CHECKBOX NAME=param4 VALUE="-">Aproximate 
match.<BR><BR> 

<INPUT TYPE=SUBMIT VALUE="Search"> 

<INPUT TYPE=RESET VALUE="Reset"> 

</FORM> 

</BODY> 

</HTML> 




FIG. 15A 
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SYSTEM AND METHOD FOR CREATING A It is another object of the present invention for the search 

SEARCH FORM FOR ACCESSING form to be configurable by an administrator. 

DIRECTORY INFORMATION j t ^ anot her object of the present invention to provide a 

„ „ . . , „ „ search form having an LDAP search filter as a search format. 

This application is related to the following U.S. Patent 5 T . ... e L . . 4 . „ 

Applications: U.S. patent application Ser. No. 08/990,246, r 11 15 ^ nother , ob f ct of * he invention to automatically 

entitled "Web Interface and Method for Displaying Direc- format the result of a search request, 

tory Information," filed Dec. 15, 1997, attorney docket no. According to one embodiment of the present invention, 

U.S. patent application Ser. No. 08/990,765, entitled, "Web these and other objects and technical advantages of the 

Interface and Method for Accessing Directory Information," invention are achieved by providing a system for creating a 

filed Dec. 15, 1997, and U.S. patent application Ser. No. search form for accessing directory information. The system 

08/990,992, entitled "Web Interface and Method for Access- comprises a server for receiving a directory request, wherein 

ing and Displaying Directory Information," filed Dec. 15, sa jd directory request comprises the search form; a request 

1^97. processor in communication with said server, wherein the 

BACKGROUND OF THE INVENTION 15 request processor responds to said directory request; a server 

1 Field of the Invention control and configuration system in communication with the 

™_ . . , . u . , . server for configuring the search form; and an administrative 

The present invention relates generally to an electronic . ^ c . . t . ... iL , 1 . 

J«„ . _.t.vLi_i„ / , . . n CI)C . m interface in communication with the server control and 

messaging system and more particularly relates to a system 

and method for creating a search form for accessing direc- configuration system. 

tory information. 20 m another embodiment, a method for creating a search 

2, Description of the Background f° rm f° r accessing directory information in accordance with 

Electronic directories are evolving into important infor- tne invention comprises the following steps: (1) determining 

mation tools having a myriad of applications. They operate an attribute to search; (2) creating a search format; (3) 

much like a printed directory; that is, they provide names, creating an input section, wherein said input section allows 

locations and other information about people, products, 2 5 a user to enter search data; (4) creating a search request 

equipment and organizations. First generation electronic based on said search format and said search data; and (5) 

directories were designed for a particular application, such creating an action string for submitting said search request, 
as an employee or e-mail system directory, and thus had 

limited usefulness outside the scope of the application. BRIEF DESCRIPTION OF THE DRAWINGS 

However, the growth of local area networks (LANs), het- „ . . . 

erogeneous e-mail networks, the Internet, and other elec- 30 . For . a more complete understanding of the present 

tronic communications media such as telephone and fax has invention, and the objects and advantages thereof, reference 

resulted in enterprises having to manage a hodgepodge of 15 now made t0 the following descriptions taken in connec- 

proprietary directory systems. These directory systems tion with the accompanying drawings in which: 

rarely interoperate, are costly to maintain, and frequently FIG. 1 is a block diagram of a Web interface system, 

contain redundant information. Enterprises today are finding 35 FIG 2 is a block diagram of a Web interface system 

a need to unify these disparate directories with a single mc i udin g a preferred embodiment of the Web to X.500 

standards-based directory to reduce maintenance costs and gateway 

provide universal access through well-defined interfaces. ' „ , „, . , . . 

Most directory vendors have chosen X.500 as the technol- FIG - 3 15 a flow chart Crating the steps for displaying 

ogy best suited to meet this need. 40 information according to a preferred embodiment of the 

Until recently, users could only access information con- invention, 

tained in an X.500 directory through specialized applica- FIG. 4 is a flow chart illustrating the steps for request 

tions called directory user agents (DUAs). DUAs were processing. 

typically limited in functionality, because (a) they were FIG. 5 illustrates an example of Read request mapping. 

tailored for particular X.500 implementations, making them 45 pjrj 5 iii ustr ates an example of List request mapping. 

unable to interoperate with other X.500 directories; and (b) nG ? ^ {& of Seafch { 

they typically displayed directory information in a fixed . , . , \, 

format, with little if any ability to customize the presentation 8 Urates the layout of a template file. 

0 f c j ata FIGS. 9(a) and 9(b) illustrate a read template file and the 

Another shortcoming of existing directory access systems 50 corresponding read request output, respectively, 

is that they fail to provide users with access to directory FIGS. 10(a) and 10(b) illustrate a simple list template file 

information via a World Wide Web ("Web") interface in a and the corresponding simple list request output, respec- 

configurable manner. Neither the format in which the infor- tively. 

mation is published nor the particular content of the infor- FIGS. 11(a) and 11(6) illustrate a complex list template 

mation is customizable. The end result therefore looks the 55 file and the corresponding complex list request output, 

same for any user requesting the information, irrespective of respectively. 

whether the user is linked via an internal network, such as FIGS. 12(a) and 12(6) illustrate a search template file and 

a corporate intranet, or via an external network, such as the the corresponding search request output, respectively. 

Internet. Moreover, the location or identification of the user FIG. 13(a) illustrates a first example of a search form 

does not affect the type of information that is provided. This 60 HTML 

may result in the disclosure of personal or otherwise secure F i G '^ m mustral es a second example of a search form 

information (such as a home telephone number) to unin- HTML 

tended recipients. '„,*.„ , „ <. 

FIG. 13(c) illustrates a search form output for the 

SUMMARY OF THE INVENTION 65 examples of FIGS. 13(a) or 13(6). 

It is therefore an object of the present invention to FIG. 14(a) illustrates a third example of a search form 

overcome these and other drawbacks of existing systems. HTML. 
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FIG. 14(b) illustrates a search form output corresponding The administrator, via Administrator Interface 106, is 

to FIG, 13(a). responsible for the map build process 210 and template build 

FIG. 14(c) illustrates a search request output correspond- process 208. Map 212 can correlate an abbreviated name to 

ing to FIGS. 14(a) and 14(6). a non-abbreviated name. Map 212 can also correlate a 

FIG. 15(a) illustrates a fourth example of a search form 5 rec * ucst t0 a tem P latc 214 

HTML, Th e request processor 202 communicates with the LDAP 

FIG. 15(b) illustrates a search form output corresponding Application Programming Interface (API) 206 in order to 

* ttj^ it/ \ access information through the LDAP Server 102 from the 

to FIG. 15(a). y^hca w h 

FIG, 15(c) illustrates a search request output correspond- jo 



ing to FIGS. 15(a) and 15(b). 



X.500 DSA 104. 

The server 200 maintains communication with Web cli- 
ents such as Web browsers 108. The server 200 to Web 

DETAILED DESCRIPTION OF THE browser 108 communication is based on the request- 

PREFERRED EMBODIMENTS response model of client/server communication. That is, the 

client sends a request to the server and the server responds. 

The preferred embodiment of the present invention and its 35 Generally, the client is requesting a resource that the server 

advantages are best understood by referring to FIGS. 1 will provide. In the case of the Web server/browser 

through 15(c) of the drawings, like numerals being used for communication, the protocol used is HTTP, 

like and corresponding parts of the various drawings. Pursuant to the HTTP protocol, the Web browser 108 

Referring to FIG. 1, which is a block diagram of a Web ^ establishes a connection with the server 200 and sends a 

interface system, X.500 Distributed System Agent (DSA) request to the server 200. This request contains a request 

104 is the database in which directory information is stored. method, a Uniform Resource Locator (URL) and a message 

Such information may include employees' photographs, containing additional information. The request method can 

phone numbers, product catalogs and the like. DSA 104 be GET, which retrieves data specified in the URL, or POST, 

communicates with ^DAP^server 102. In^a^pfefeiTed ^ which sends information to the server for firer action. The 

embo^imelft^the-protocol-used URL specifies a resource accessible by the server. The 

duxcfoiyja'ccess^p^ message contains request modifiers, client information, and 

Qo-Uie^eb-torX^OO possibly a body of data. The body of data contains infor- 

^re^uesj-^^anrLDAPrreque^^ The Web to mation that the server will use for further action. 

X.500l^ateway 100 may be further coupled with adminis- 3Q ^ server 2 fjo responds with a status code and a message 

trative interface 106, which permits access by an containing additional information. The status code may be: 

administrator, and Web browser 108, which permits access 0 K; a bad request has occurred; an internal server error has 

by a user. Using the Web browser 108, a user can access occurred; the request method is not implemented by the 

information about people, products and resources in server; or the server is unavailable. The message contains 

scalable, robust, secure messaging directories (such as ^ information, resource information and possibly a 

X.500 directories), and can publish multiple views of such body ofdata. The body of data contains the resource that was 

information. This information can be on an internal network requested or an error message 

for enterprise use or on a public network accessible by ^ t ^ 2Q2 provk)es ^ (o ^ end 

various indiv.duals, organizations and the like. ^ The server 200 starts the request processing and returns 

The Web to X.500 gateway 100 provides a user-friendly 40 l0 its eve nt-driven loop. A preferred embodiment of the 

way to publish enterprise directory information. Adminis- invention handles a plurality of requests, including retrieve 

trators can easily publish directory information that users resource, Read distinguished name ("DN"), List distin- 

can access, search and view from Web browsers, LDAP- gu i s h e d name and Search distinguished name, 

enabled clients and X 500-based applications. The Web to To ^ a retrieve resourcc ^ 

X.500 gateway 100 allows administrators to easily define 45 £ a GET frQm ^ ^ ^ ^ URL ^ ^ form 

data mappings and conversions from a wide variety of data and name o{ resource The resource te an ^ 

sources, thereby integrating multi-sourced content into a Qr ^ documen( accessib , e by , ne servef ^ galeway 

irec ory. responds with this resource. 

FIG. 2 illustrates the topology of a preferred embodiment „ a a- *• ua /t> a\ * «u 

riIf . v rrt/ v , mn tl ni u , v cnn * To process a read distinguished name (Read) request, the 

of Web to X.500 gateway 100. The Web to X.500 gateway 50 / , 6 1TT1T . f v ' ,7 ., , 

& f 3 . „, , x -, u f . ■ L client sends a GET with a URL in the form Distinguished 

100 includes a server (such as a Web server) 200, which )>TL 4 „ , . . f , 

- v t . - ' name. The gateway processes a Read as a single entry read 

accepts requests for directory information; request processor 0 f the DN 
202, which responds to the requests; map 212, which 

correlates the requests to template files (i.e., request To process the list distinguished name (List) request, the 

mapping) and correlates abbreviated names to unabbrcvi- 55 client »nds a GET with a URL in the form "Distinguished 

ated names (i.e., friendly name mapping); and template files name?" The gateway processes a List as a single entry read 

214, which contain templates that dynamically control the of the DN and a one level list of the DN - 

publishing of the requested directory information. A user To process the search distinguished name request 

may access the server 200 via Web Browser 108 through (Search), the client sends a POST with a URL in the form: 

Sockets Application Programming Interface (Sockets API) eo "Distinguished name"?"?Search format". The gateway pro- 

204. Additionally, an administrator controls and configures cesses a Search as a single entry read of the DN and a full 

the server 200 via Server Control and Configuration system sub-tree search of the DN. 

218. FIG. 3 illustrates the steps for displaying directory 

In order to update and build the map and template files, a information, according to a preferred embodiment of the 

map build process 210 and a template build process 208 are 65 invention. In step 300, the server accepts at least one 

used. Map build 210 creates and updates map 212, while information request from a Web browser. In step 302, the 

template build 208 creates and updates template files 214. server retrieves at least one entry from a directory respond- 
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ing to the information request. In step 304, the map corre- 
lates the entry with a template file to create a response, the 
template file including predetermined criteria for controlling 
the display of the entry. In step 306, the response is pub- 
lished according to predetermined criteria. The response 5 
may be published by the request processor 202 to a user via 
a public network, such as the Internet, or a private network, 
such as a corporate intranet. 

The map 212 is used during request processing to link one 
object to another. There are two types of mappings used in 10 
request processing: request mappings and friendly name 
mappings. Request mappings are used during request pro- 
cessing to determine which template file should be used. The 
request mappings link a portion of the X.500 directory to a 
template file. Request mappings include Read request 15 
mappings, List request mappings and Search request map- 
pings. 

A specific mapping belonging to the Read, List or Search 
set may be one or two entity specific types: distinguished 
name (DN) and/or object class (OC). A distinguished name 20 
request mapping correlates a specific DN to a template file. 
If a request of the specified operation type occurs for this 
specific DN, then this mapping is used. An object class 
request mapping correlates all DNs of a specific object class 
to a template file. If a request of the specified operation type 25 
occurs for a DN with this specific OC, then this mapping is 
used. A distinguished name request mapping preferably 
always overrides an object class request mapping. 

FIG. 4 illustrates the steps for request processing in more 
detail. First, it is determined whether the request is for a DN 
402. If the request is not for a DN, the requested resource is 
read 404. If the request is for a DN, it is determined whether 
the DN is mapped 406. If the DN is not mapped, the object 
class of the DN is retrieved from the X.500 directory via 
LDAP 408 and this OC is used to find a template, assuming 
the OC is mapped 412. If the OC is not mapped, an 
appropriate error message is used 410. If the DN is mapped, 
the DN is used to find a template 412. If a template is found 
and the request is a Read or List request, the tags of the 
template are filled in via LDAP 414. If the template is found 4 
and the request is a Search request, a search filter is created 
from the input data and the search format The template is 
then filled in via LDAP 414. If the template is not found, an 
appropriate error message is used 410. A response is sent to 
the browser 416. 

In the following description, ocfile.html and dnfile.html 
are used as filename examples. In practice, the filenames 
would be more descriptive and different for each request 
mapping type. 50 

Read request mapping is used when a Read request is 
received. A Read request mapping links a portion or multiple 
portions of the X.500 directory to a specific template file. 
Referring now to FIG. 5, which illustrates an example of 
Read request mapping, the relationship between a Read 55 
request mapping, the X.500 directory and a template file can 
be seen. This example shows both DN and OC request 
mappings. 

For the DN request mapping 502, a single portion of the 
X.500 directory is mapped. The entry o=XYZCorp,c=US is 60 
mapped to the template file dnfile.html 504. The file dnfile- 
.html 504 includes a template for the organization object 
class. A response based on dnfile.html is created for a Read 
request of o«XYZCorp,c=US. 

For the OC request mapping 506, multiple portions of the 65 
X.500 directory are mapped. For example, the object class 
organization is mapped to the template file ocfile.html 508. 



,362 Bl 

6 

The file ocfile.html 508 includes a template for the organi- 
zation object class. A response based on ocfile.html is 
created for a Read request of any organization. 

List request mappings are used when a List request is 
received. A List request mapping links a portion or multiple 
portions of the directory to a specific template file. Referring 
now to FIG. 6, which illustrates an example of List request 
mapping, the relationship between a List request mapping, 
the X.500 directory and a template file can be seen. This 
example shows both DN and OC request mappings. 

For the DN request mapping 602, a single portion of the 
X.500 directory is mapped. The entry o=XYZCorp,c=US is 
mapped to the template file dnfile.html 604. The file dnfile- 
.html 604 includes tags for the organization object class and 
a template for the organizationalUnit object class and any 
other immediate subordinate object class. A response based 
on dnfile.html is created for a List request of o«XYZCorp, 
c«US. 

For the OC request mapping 606, multiple portions of the 
X.500 directory are mapped. For example, the object class 
organization is mapped to the template file ocfile.html 608. 
The file ocfile.html 608 includes tags for the organization 
object class and a template for the organizationalUnit object 
class and any other immediate subordinate object class. A 
response based on ocfile.html is created for a List request of 
any organization. 

Search Request mappings are used when a Search request 
is received. A request mapping that is a member of this set 
links a portion of the directory (or multiple portions) to a 
specific template file. Referring now to FIG. 7, which 
illustrates an example of Search request mapping, the rela- 
tionship between a search request mapping, the X.500 
directory and a template file can be seen. This example 
shows both DN and OC request mappings. 

For the DN request mapping 702, a single portion of the 
X.500 directory is mapped. The entry o=XYZCorp,c=US is 
mapped to the template file dnfile.html. The file dnfile.html 
704 includes tags for the organization object class, a tem- 
plate for the organizationalUnit object class, a template for 
the person object class and any other object class in the full 
sub-tree. A response based on dnfile.html is created for a 
Search request of o=XYZCorp,c=US. 

For the OC request mapping 706, multiple portions of the 
directory are mapped. The object class organization is 
mapped to the template file ocfile.html. The file ocfile.html 
708 includes tags for the organization object class, a tem- 
plate for the organizationalUnit object class, a template for 
the person object class, and any other object class in the fill 
sub-tree. A response based on ocfile.html is created for a 
Search request of any organization. 

Friendly name mappings are used during request process- 
ing to replace abbreviated names with more easily under- 
stood names. Two types of friendly name mappings are 
attribute mappings and country mappings. Attribute map- 
pings are used during request processing to replace (in a 
response) the X.500 directory attributes with the full name 
of the attribute. An example of attribute mapping is using 
"cn" for "Common Name." Country mappings are used 
during request processing to replace (in a response) returned 
country names with the full name of the country. Some 
examples of country mappings are "AR" for "Argentina," 
"CA" for "Canada," and "US" for "United States." 

Any of the mappings, including read request mappings, 
fist request mappings, search request mappings, attribute 
mappings and country mappings, may be configured by the 
administrator. Mapping administration preferably is based 
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on schema and directory information. Attribute mappings 
should be maintained for all attributes within the directory 
that will be displayed. Country mappings should be main- 
tained for all countries within the directory that will be 
displayed. Request mappings should be maintained for 
every object class that a request will be executed. Each of 
those request mappings requires a template file to fulfill the 
request. In the event that a response will look different for 
a specific entry, a distinguished name request mapping must 
be maintained. 

The template files 210 are used in request processing to 
create a response. Files include non-template files and 
template files. Non- template files are any files that act as a 
gateway response to a retrieve resource request. Examples of 
non-template files are standard HTML files and image files. 

Template files are the files that are used to dynamically 
build responses for Read, List or Search requests. FIG. 8 
illustrates a layout of a template file. Template files include 
general text 802 and templates 804. The general text sections 
802 of the template files include HTML codes and special 
gateway tags, and do not correspond to a specific object 
class. The general text sections 802 are preferably always 
displayed and any gateway tags present are filled with data 
from the DN in the request. The template sections 804 of the 
template file include HTML codes and special gateway tags. 
A template 804 defines a section of the template file that is 
for a specific object class. A template section 804 is pref- 
erably only displayed if it corresponds to an object class that 
is present in the Read, List or Search request. 

The gateway tags include TEMPLATE, DN, UPLEVEL, 
ATTR, VAL, LINK and LOOP. The TEMPLATE tag indi- 
cates to the gateway that a template for an object class is 
being defined. The template may contain any HTML codes 
in addition to the other gateway tags. A single HTML file 
may contain any number of templates. Any templates that 
are not used will be ignored and discarded in the HTML 
output. The format of the TEMPLATE tag is: ^TEMPLATE 
OCV'objectClass" [options]% % /TEMPLATES. The string 
objectQass indicates which object class is to be used for the 
template. The tag % /TEMPLATE% indicates the end of the 
template to the gateway. One option is the DISPLAY option, 
which controls how many values are displayed for a List or 
Search request. The DISPLAY option may be ONE or ALL. 
If the DISPLAY option is not present, the template defaults 
to DISPLAY=" ALL". If the ONE option is specified, only 
the first value found appears in the list. 

The DN tag indicates to the gateway that the current 
distinguished name should be substituted. The format of the 
DN tag is % DN [options]%. If no options are present, the 
relative distinguished names (RDNs) are separated by com- 
mas. The option PRETEXT="text" places text before each 
RDN. The option POS'ITEXT="text" appends text after 
each RDN. The option DELIMIT«"text" places text 
between each RDN. In a Read template file, the current DN 
is defined as the DN in the Read request. In a List or Search 
template file, the definition depends on the position of the 
DN tag in the file. If the DN tag is located in the general text 
section, it is defined as the DN in the List or Search request. 
If the DN tag is inside a loop, it is defined as the current DN 
that has been returned by the List or Search request from the 
X.500 directory. 

The UPLEVEL tag generates a hyperlink to a List request 
on the parent DN of the current DN. The format of the 
UPLEVEL tag is %UPLEVEL%[text/tags] %/UPLEVEL%. 
[text/tags] may be any valid HTML and/or the gateway tags 
ATTR or VAL. The UPLEVEL tag acts like the <A HREF- 
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""></A>HTML control code. Using the enclosed text, it 
creates a hyperlink to a List request on the parent DN of the 
current DN. 

The ATTR tag replaces in the response the abbreviated 
X.500 attribute with the friendly name from the attribute 
mappings. The format of the ATTR tag is %ATTR NAME- 
"name"%. The string name indicates which X.500 attribute 
mapping to use. If no mapping is found, the abbreviated 
X.500 attribute is used. This is a text replacement function. 

The VAL tag retrieves the values of an X.500 attribute and 
places them in the HTML document. The format of the VAL 
tag is %VAL NAME="name"%. The string name indicates 
which X.500 attribute to retrieve. 

The LOOP tag is used to specify that a portion of a 
template should be repeated for all corresponding DNs. The 
format of a LOOP tag is: %LOOP[options]%[loop 
text]%/LOOP%. The option SPLIT«" number" indicates that 
the returned list should be split into "number" of segments. 
The option SEGMENT="number" indicates the segment 
that should be processed in this loop. The text may contain 
any valid HTML and the gateway tags LINK, ATTR, VAL 
or DN. LOOP tags may be used in List and Search templates. 

The LINK tag acts like the <A HREF=""x/A>HTML 
control code. Using the enclosed text, it creates a hyperlink 
of a Read request of the current DN. This tag is generally 
used in a LOOP for a Search or List request, creating links 
to the DNs listed. The format of a LINK tag is: %LINK% 
[text/tags]% / LINK%. [text/tags] may be any valid HTML 
and/or the gateway tags ATTR or VAL. 

Template files combine HTML codes with the special 
gateway tags to allow the display of information from an 
X.500 directory. A Read template file is used to display data 
about one specific X.500 directory entry. To process a Read 
request, the gateway expects a GET from the client with the 
URL in the form: "Distinguished name". A template should 
be defined in the template file for the object class of the Read 
DN. When the template file is processed, any object class 
that defines the DN will be processed and displayed. A Read 
template file may include the following tags in its general 
text or template file: ATTR (X.500 attribute), VAL (X.500 
value), DN (current distinguished name), UPLEVEL 
(hyperlink to List parent DN) and LINK (hyperlink to Read 
current DN). 

FIGS. 9(a) and 9(b) illustrate a read template file and the 
corresponding read request output, respectively. The read 
request output may be in any number of formats, including 
the one illustrated in FIG. 9(b). Given the template file 
illustrated in FIG. 9(a), and the Read request of http:// 
127.0.0. l:8888/ou%3dSALES%2co%3dXYZCorp% 
2cc%3dUS, the response would be that illustrated in FIG. 
9(6). Based on directory information, the %DN% 902 fol- 
lowing the <TITLE> 904 is replaced with ou«SALES,o~ 
XYZCORP,c = US. The %TEMPLATE 
OCV'organizationalUnif'% 906 and %/TEMPLATE% 908 
define a template section for the organizationalUnit object 
class. Based on attribute mappings, the %AJ J K NAME%« 
"ou"% 910 is replaced with Organizational Unit. Based on 
directory information, the %DN% 912 is replaced with 
ou-SALES,o«XYZCORP, c=US. Based on directory 
information, the oval name-"ou"% 914 is replaced with 
SALES. The resulting text (<A HREF="ou=SALES,o= 
XYZCORP, coUS?'*>SALES</A>) is displayed by the 
browser as a hyperlink to list SALES. 

Based on attribute mappings, the %A1TR NAME«"sa"% 
916 is replaced with Street Address. Based on directory 
information, the %VAL NAME-"sa"% 918 is replaced with 
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1 XYZCorp Way. Based on attribute mappings, the %ATTR 
NAME«'T'% 920 is replaced with Location. Based on 
directory information, the %VAL NAME«T'% 922 is 
replaced with Anywhere. Based on attribute mappings, the 
%ATTR NAME«"sopn"% 924 is replaced with State or 5 
Province. Based on directory information, the %VAL 
NAME="sopn"% 926 is replaced with XX. Finally, the 
%UPLEVEL% 928 and the %/UPLEVEL% 930 define an 
uplevel section. Based on directory information, the result of 
the uplevel section (<A HREF="o=XYZCORP,c«US?">Up 1Q 
to XYZCORP</A>) is displayed by the browser as a link to 
list XYZCorp. 

A List template file displays information for an X.500 
directory entry and those entries one level below the entry. 
To process the List request, the gateway expects a GET from 15 
the client with the URL in the form: "Distinguished name"? 

A template is preferably defined in the template file for 
each object class that may be used to display directory 
entries under the distinguished name. Tags are placed in the 
general text section for the DN to List. The gateway tags that 2 q 
may be used in the general text or template of the List 
template file include ATTR (X.500 attribute), VAL (X.500 
value), DN (current distinguished name), UPLEVEL 
(hyperlink to List parent DN) and LINK (hyperlink to Read 
current DN). LOOP, which causes the gateway to loop 2 s 
through all the DNs that correspond to the template, may be 
used in the template of the List template file. 

FIGS. 10(a) and 10(b) illustrate a simple list template file 
and the corresponding simple list request output, respec- 
tively. Given the template file illustrated in FIG. 10(a), and 30 
the List request http:/127. 0.0.1 :8888/ 
ou%3dSALES%2co%3d XYZCorp%2cc%3dUS?, the 
response would be that illustrated in FIG. 10(6). Based on 
directory information, the %DN% 1002 is replaced with 
ou=SALES, o-XYZCORP, c«US. Based on attribute 35 
mappings, the %ATTR NAME="ou"% 1004 is replaced 
with Organizational Unit. Based on directory information, 
the %VAL NAME="ou"% 1006 is replaced with SALES 
The % TEMPLATE OC-"pilotperson"% 1008 and 
%/TEMPLATE% 1010 define a template section for the 40 
pilotPerson object class. The %LOOP% 1012 and 
%/LOOP% 1014 define a loop section that will be repeated 
for every pilotPerson found in the directory. 

The following refers to the first pilotPerson found in the 
directory. Based on attribute mappings, the %ATTR 45 
NAME="cn M % 1016 is replaced with Common Name. The 
%LINK% 1018 and %/LINK% 1020 defines a link section 
for the current pilotPerson. Based on directory information, 
the %VAL NAME="cn"% 1022 is replaced with John Doe. 
The result of the link section (<A HREF="cn=JOHN DOE, 50 
ou=SALES, o=XYZCORP,c=US">John Doe</A>) is dis- 
played by the browser as a link to read John Doe (see FIG. 
10(b)). Based on attribute mappings, the %ATTR NAME- 
"t"% 1024 is replaced with Title. Based on directory 
information, the %VAL NAME="t"% 1026 is replaced with 55 
Salesman. The LOOP is now repeated for the next pilotPer- 
son found in the directory. Based on attribute mappings, the 
%ATTR NAME="cn"% 1016 is replaced with Common 
Name. The %LINK% 1018 and %/LINK% 1020 defines a 
link section for the current pilotPerson. Based on directory 60 
information, the %VAL NAME«"cn"% 1022 is replaced 
with Jane Doe. The result of the link section (<A HREF= 
"cn=JANE DOE,ou«SALES,o=XYZCORP,c«US">Jane 
Doe</A>) is displayed by the browser as a link to read Jane 
Doe (see FIG. 10(b)). Based on attribute mappings, the 65 
%AITR NAME-"t"% 1024 is replaced with Title. Based on 
directory information, the %VAL NAME-"t"% 1026 is 
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replaced with Manager. The %UPLEVEL% 1028 and 
%/UPLEVEL% 1030 define an uplevel section. Based on 
directory information, the result of the uplevel section (<A 
HREF="ooXYZCORP, c=US?">Up to XYZCorp</A>) is 
displayed by the browser as a link to list XYZ Corp (see 
FIG. 10(b)). 

FIGS. 11(a) and 11(b) illustrate a complex list template 
file and the corresponding list request output, respectively. 
Given the template file illustrated in FIG. 11(a), and the List 
request http : //1 27 .0 .0 . 1 : 8888/ou %/ 

3dSALES%2co%3dXYZ Corp%2cc%3dUS?, the response 
would be that illustrated in FIG. 11(b). Based on directory 
information, the %DN% 1102 is replaced with ou=SALES, 
o«XYZCORP, c»US. Based on directory information, the 
%DN D ELI MI T = "<BR>" PRETEXI- 

"<STRONG>"POSTTEXT="</STRONG>% 1104 is 
replaced with <STR O NG >ou = S ALES </ 
STRONGxBR><STRONG>o«XYZCORP</ 
STRONGxBR><STRONG>coUS </STRONG>. Based 
on attribute mappings, the %ATTR NAME="ou"% 1106 is 
replaced with Organizational Unit. Based on directory 
information, the %VAL NAME="ou"PRETEXT= 
"<STRONG>"POSTTEXT=</STRONG>"% 1108 is 
replaced with <STRONG>SALES</STRONG>. Based on 
attribute mappings, the %ATTR NAME="sa "% 1110 is 
replaced with Street Address. Based on directory 
information, the %VAL NAME=»"sa"% 1112 is replaced 
with 1 XYZCorp Way. Based on attribute mappings, the 
%ATTR NAME«"1"% 1114 is replaced with Location. 
Based on directory information, the %VAL NAME«T'% 
1116 is replaced with Anywhere. Based on attribute 
mappings, the %ATTR NAME="sopn"% 1118 is replaced 
with State or Province. Based on directory information, the 
%VAL NAMEo"sopn"% 1120 is replaced with XX. Based 
on attribute mappings, the %AITR NAME«"d"% 1122 is 
replaced with Description. Based on directory information, 
the %VAL NAME="d"POSTTEXT="</Ll>"PRETEXT= 
"<LI>"% 1124 is replaced with <LI>With X.500 Directory 
emphasis </LlxLI>The sales unit</LI><LI specializing 
in messaging services</LI>. The %TEMPLATE 
OC«"pilotPerson"% 1126 and %/TEMPLATE% 1128 
define a template section for the pilotPerson object class. 
The %LOOP% 1130 and %/LOOP% 1132 define a loop 
section to be repeated for every pilotperson found in the 
directory. 

The following refers to the first pilotperson found in the 
directory. The %LINK% 1134 and %/LINK% 1136 defines 
a link section for the current pilotPerson, Based on directory 
information, the %VAL NAME="cn"% 1138 is replaced 
with John Doe. The result of the link section (<A HREF= 
"cn«JOHN DOE, ou=SALES, o=XYZCORP,c=US">John 
Doe</A>) is displayed by the browser as a link to read John 
Doe. Based on directory information, the %VAL NAME= 
"t"% 1140 is replaced with Salesman. 

The following refers to the second pilotPerson found in 
the directory. The %LINK% 1134 and %/LINK% 1136 
defines a link section for the current pilotperson. Based on 
directory information, the % VAL NAME="cn"% 1138 is 
replaced with Jane Doe. The result of the link section (<A 
HREF«"cn-JANE DOE,ou«SALES,o«XYZCORP, 
c-US">Jane Doe</A>) is displayed by the browser as a link 
to read Jane Doe. Based on directory information, the % 
VAL NAME-"t"% 1140 is replaced with Manager. 

The following refers to the third pilotperson found in the 
directory. The %LINK% 1134 and %/LINK% 1136 defines 
a link section for the current pilotperson. Based on directory 
information, the %VAL NAME-"cn"% 1138 is replaced 



03/29/2004, EAST version: 1.4.1 



US 6,192, 

11 

with John Public. The result of the link section (<A HREF- 
"cn-JOHN PUBLIC, ou«SALES,o-XYZCORP, 
c=US">John Public</A>) is displayed by the browser as a 
link to read John Public, Based on directory information, the 
%VAL NAME="t"% 1140 is replaced with Receptionist. 5 

The 9&TEMPLATE 0O"device"% 1142 and 
%/TEMPLATE% 1144 define a template section for the 
device object class. The %LOO?% 1146 and %/LOOP% 
1148 define a loop section to be repeated for every device 
found in the directory. The following refers to the first device 10 
found in the directory. The %LINK% 1150 and %LINK% 
1152 defines a link section for the current device. Based on 
directory information, the %VAL NAME«"cn"% 1154 is 
replaced with Directory Publisher. The result of the link 
section (<A HREF-"cn=DIRECTORY PUBLISHER,ou~ *5 
SALES, o«XYZCORP,c-US">Directory Publisher </A>) is 
displayed by the browser as a link to read Directory Pub- 
lisher. Based on directory information, the %VAL NAME= 
"d" DELIMIT-", "% 1156 is replaced with X.500 Directory, 
LMS Names Publisher. 20 

The following refers to the second device found in the 
directory. The %LINK% 1150 and %/LINK% 1152 defines 
a link section for the current device. Based on directory 
information, the %VAL NAME«"cn"% 1154 is replaced 
with LMS. The result of the link section (<A HREF="cn= 25 
LMS,ou-SALES,o=XYZCORP,c=US">LMS</A>) is dis- 
played by the browser as a link to read LMS. Based on 
directory information, the %VAL NAME-"d" DELIMIT- 
""% 1156 is replaced with The Lotus Message Switch. The 
%UPLEVEL% 1158 and %/UPLEVEL% 1160 define an 30 
uplevel section. Based on directory information, the result of 
the uplevel section (<A HREF="o=XYZCORP,c=US?">Go 
UP To Previous Level</A>) is displayed by the browser as 
a link to list XYZCorp. 

To conduct a search, the search template file that is used 
to create the response and the search form into which the 
search data is entered are both created. To process the 
search, the gateway expects a POST from the client with 
URL to be in the form: "Distinguished name*'?"? Search 4Q 
format". 

A Search template file is used to display information for 
an X.500 entry and all entries below that DN that meet 
certain criteria. A Search template file is setup in the same 
format as a List template file. In the case of a Search 45 
template file, a template should be defined for each object 
class that may exist in the sub-tree of the distinguished 
name. 

The following tags may be used in a Search template file: 
ATTR (X.500 attribute); VAL (X.500 value); DN (current 50 
distinguished name); UPLEVEL (hyperlink to List parent 
DN); LINK (hyperlink to Read current DN); and LOOP 
(causes the gateway to loop through all the DNs that 
correspond to the template). All of these tags may be used 
in the template, while all but LOOP may be used in general 55 
text. 

FIGS. 12(a) and 12(b) illustrate a search template file and 
the corresponding search request output. Given the Search 
template file illustrated in FIG. 12(a), and the submission of 
search for commonName ending in Doe and objectClass 60 
equal to pilotPerson, the response would be that illustrated 
in FIG. 12(6). Based on directory information, the %DN% 
1202 is replaced with ou=SALES,o=XYZCORP,c»US. 
Based on attribute mappings, the %ATTR NAME="ou"% 
1204 is replaced with Organizational Unit. Based on direc- 65 
tory information, the %VAL NAME«"ou"% 1206 is 
replaced with SALES. The %TEMPLATE OC=" pilotPer- 
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son"% 1208 and %/TEMPLATE% 1210 define a template 
section for the pilotPerson object class. The %LOOP% 1212 
and %/LOOP% 1214 define a loop section that will be 
repeated for every pilotPerson found in the directory. 

The following refers to the first pilotperson found in the 
directory. The %LINK% 1216 and %/LINK% 1218 defines 
a link section for the current pilotperson. Based on directory 
information, the %VAL NAME-"cn"% 1220 is replaced 
with John Doe. The result of the link section (<A HREF« 
"cn-JOHN DOE,ou=SALES,o=XYZCORP, c=US">John 
Doe</A>) is displayed by the browser as a link to read John 
Doe. 

The following refers to the second pilotPerson found in 
the directory. The %LINK% 1216 and %/LINK% 1218 
defines a link section for the current pilotPerson. Based on 
directory information, the %VAL NAME="cn"% 1220 is 
replaced with Jane Doe. The result of the link section (<A 
HREF="cn=JANE DOE,ou=SALES, o=XYZCORP,c= 
US">Jane Doe</A>) is displayed by the browser as a link to 
read Jane Doe. 

The %TEMPLATE 0O"device"% 1222 and 
%/TEMPLATE% 1224 define a template section for the 
device object class. Since the search was for cn ending in 
Doe and objectClass equal to pilotPerson, this template 
section is ignored. 

To create a search form, an administrator: (1) decides on 
what attributes to search and what distinguished name to 
use; (2) creates the search format and numbers the param- 
eters; (3) creates the ACTION string; (4) creates the INPUT 
sections of the form; and (5) creates a template file with 
template structures for any object classes that may be 
returned from the search request. In defining a search 
format, a plurality of search formats are contemplated. For 
example, the search format may be an LDAP search filter as 
defined in RFC 1960, with gateway specific modifications. 
Instead of the values for the attributes, there are placeholders 
that are used by the gateway to substitute the input data. The 
gateway receives the search format and the input data at the 
time the Search request is made. The gateway then creates 
an actual LDAP search string from the search format and the 
input data. . 

The placeholders include the following: $N, which is the 
value to search for; $T, which is a NOT character (!); $F, 
which is a filter type for the equality (~=, >=, <«); and $C, 
which is a comparison operator (|, &). The filter types are 
defined as follows: ~= means "approximately equal to"; >= 
means "greater than or equal to"; and <= means "less than 
or equal to". The comparison operator | (vertical bar) means 
"or" and & (ampersand) means "and." The placeholders are 
used to create the search string format. Each placeholder has 
an index value associated with it. The index associated with 
the placeholder is the number associated with the order in 
which they appear in the string. Indexing the parameters 
allows the gateway to replace placeholders with actual data. 

Once a search format is defined, a form is built. The 
following HTML tags are used when building a form: (1) 
METHOD, which is the type of request that is sent when the 
form is submitted; it preferably is POST; (2) ACTION, 
which is the URL to be submitted; it preferably is in the 
form: "Distinguished name"?"? Search format"; and (3) 
INPUT, which is an input area on the form which follows the 
form: <INPUT TYPE=type NAME-name VALUE=value>. 
The TYPE value is preferably one of the following: TEXT, 
which is an edit box for entering data; RADIO, which is a 
radio button for selecting one of multiple choices; 
CHECKBOX, which is a check button for turning an option 
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on or off; SUBMIT, which is a submit button; or RESET, 
which is a reset button. 

In order for the gateway to create the LDAP filter, the 
form is set up to associate the input areas with the place- 
holders. This is done by giving the NAME parameter a value 
containing the index of the placeholder, and having the 
VALUE value reflect the string that is to be used in the 
search filter. The NOT operator is a checkbox in the form. 
Since it is either on or off, only one input line is needed. The 
VALUE value is an exclamation mark "!". For example, it 
may look like: <INPUT TYPE«CHECKBOX NAME- 
param2 VALUE-" !">Not. 

The COMPARISON operator is a radio button within the 
form. The form does not need to display these characters, but 
it is set up to send them to the gateway for processing. The 
COMPARISON operator is selected by displaying the two 
possible values. The NAME value for both selections must 
be the same in order to have the form send only one of the 
values. The VALUE value for the And operator must be an 
ampersand and the VALUE for the Or operator must be a 
vertical bar. One of the radio buttons is automatically 
selected by using the CHECKED parameter. For example, it 
may look like: <INPUT TYPE-RADIO CHECKED 
NAME=paraml VALUE«"&">And. It may also look like: 
<INPUT TYPE-RADIO NAME=paraml VALUE="|">Or. 

The FILTER type operator is a radio button or a checkbox 
within the form. If more than one choice is given, it 
preferably is a radio button. If only one choice is given, it 
preferably is a checkbox. The filter type is used to modify 
the equality comparison in the filter. It can modify it to be 
greater than, less than or approximate to. 

If more than one choice is given, the NAME value for all 
selections must be in the same order to have the form send 
only one of the values, or possibly no value which will leave 
the equality unaffected. The VALUE value for the greater 
than operator is the greater than sign (>). The VALUE value 
for the less than operator is the less than sign (<). The 
VALUE value for the approximate operator is the tilde (-). 
It is not necessary to use the CHECKED parameter because 
the default is no value. One example of a FILTER type 
operator is: <INPUT TYPE=RADIO NAMEoparam3 
VALUE="<">Less Than. 

NAME is a text edit box in the form. If no text is typed 
into the box, an asterisk (*) is assumed. There are no 
restrictions on the TEXT input. The user can type wildcards 
into the text to modify the search criteria. One example is the 
following: Surname:<INPUT TYPE-TEXT NAME= 
param4 SIZE-32 MAXLENGTH=2000>. 

Preferably all forms have a SUBMIT and RESET button. 
Selecting the SUBMIT button sends the ACTION value and 
input data to the gateway. Selecting the RESET button clears 
all the data entered and sets all buttons to their default 
values. 

FIG. 13(a) illustrates a first example of a search form 
HTML. This is for a search on the attribute commonName. 
The LDAP filter may look like: (cn«*Doe), which creates a 
search on the commonName attribute with a value ending in 
Doe. The search format is: (cn$F=$N) 1302, where $F 
stands for the equality filter type and $N stands for the value 
of commonName. 

The above search may be modified to only search entries 
with an object class of pilotPerson. FIG. 13(6) illustrates a 
second example of a search form HTML. The LDAP filter 
might look like: (&(cn«*DoeXobjectClass«pilotPerson)). 
This is a search on the commonName with a value ending in 
Doe and an objectClass with a value of pilotperson. The 
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search format is: (&(cn$F=$N)(objectClass=pilotPerson)) 
1304, where $F stands for the equality filter type and $N 
stands for the value. FIG. 13(c) illustrates a search form 
output for the examples of FIGS. 13(a) or 13(6). 

The above example may be modified to allow the user to 
look for entries other than pilotPerson, as illustrated by the 
search form HTML of FIG. 14(a). The search format would 
be: (&(cn$F=$N)($T(objectClass=pilotPerson))) 1402, 
where $F stands for the equality filter type and $N stands for 
the value of commonName. FIG. 14(b) illustrates a search 
form output corresponding to FIG. 14(c), and FIG. 14(c) 
illustrates the corresponding search request output. 

A search may also be conducted on the attribute com- 
monName and/or the attribute title, as illustrated by the 
search form HTML. The LDAP filter may look like: (&(cn« 
J*)(t~=Manager)). This is a search on the commonName 
attribute with a value beginning with J and a title approxi- 
mately equal to Manager. The search format is: ($C(cn$F= 
$N)(t$F=$N)) 1502, where SF stands for the equality filter 
type, $N stands for the value and $C stands for a compare. 
FIG. 15(b) illustrates a search form output corresponding to 
FIG, 15(a), and FIG. 15(c) illustrates the corresponding 
search request output. 

Another embodiment of the invention automatically for- 
mats search results into clickable lists, tables, frames and 
other constructs represented in HTML. For example, once a 
person is selected from an employee locator, his Internet 
e-mail address may be selected and automatically placed in 
the "TO" field of the user's Internet mail client. 

In another embodiment of the invention, an administrator 
can configure various system parameters, including server 
parameters, LDAP parameters, logging parameters and 
administrator parameters. 

A Server page allows configuration of parameters relevant 
to the server. These parameters include connection and 
HTML information. The connection parameters includes 
Port, Maximum Number of Connections, Maximum Num- 
ber of Backlog Connections, Idle Disconnect Time-out and 
Watchdog Timer. Port is the port on which the gateway 
listens for requests. Maximum connections is the maximum 
number of requests the gateway processes at one time. This 
allows the gateway to refuse connections after this maxi- 
mum has been reached. Maximum backlog connections is 
the maximum number of requests the gateway will allow 
pending. Idle disconnect time-out is the number of seconds 
the gateway allows a request to process before attempting to 
close the connection. This allows the gateway to limit the 
amount of time a connection is alive; when this limit is 
reached, the gateway attempts to close the connection. 
Watchdog timer is the number of seconds between gateway 
checks for idle disconnects. This allows the gateway to 
check all open connections to see if they should be closed. 
Base path is the path for all requests; all relative URLs are 
preferably relative to this directory. Default file is the default 
HTML file. When a request is made, this file is sent. 

An LDAP page allows configuration of the LDAP con- 
nection parameters. LDAP parameters include host 
parameters, bind parameters and search time-out param- 
eters. Host parameters include Address and Port. The 
Address parameter is the IP address of the LDAP server, 
which allows the gateway to execute LDAP searches on the 
X.500 directory through the LDAP server. Port is the port of 
the LDAP server. Bind parameters include User Name and 
Password. User name is the user (Distinguished Name) the 
gateway should bind as. Password is the password the 
gateway should use when binding. Search time-out param- 
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eters include Infinite LDAP Time-out and LDAP Search 
Time-out. The former asks whether it is desired for the 
LDAP searches to have no time-out. An LDAP search can be 
configured to have no time-out value. This means that an 
LDAP search will wait infinitely for results. The latter asks 
what the LDAP searches time-out value is. An LDAP search 
can be configured to have a specific time-out value. This 
means that an LDAP search will wait only this amount of 
time for results. If this wait time is reached, an error will 
occur. This parameter is only available if the Infinite LDAP 
Time-out parameter is not chosen. 

A Log page allows configuration of the logging capabili- 
ties of the gateway. Logging parameters include Number of 
Files, Records per File and Log Level. With respect to the 
number of files, the administrator is asked how many log 
files should be maintained. Once the maximum number of 
log records is reached in a log file, the gateway creates a new 
log file, up to the number of files specified here. Once that 
number is reached, the oldest log file is overwritten. With 
respect to Records per File, the administrator is asked what 
is the maximum number of records per log file. The gateway 
writes a specified number of log records to a log file before 
closing that log file and creating a new one. With respect to 
Log Level, all log messages defined by the gateway are 
assigned a log level. Only log messages associated with the 
specified logging level are output to the log. Logging levels 
include MINIMAL, NORMAL, INTENSIVE and DEBUG. 
These levels indicate the quality of information the gateway 
writes to the log files, with MINIMAL being the minimum 
level and DEBUG being the maximum level. 

An Administrator page allows configuration of the 
Administrator application. The parameter countries is the 
list of countries that are available for the administrator 
application. The schema file parameter is the schema file 
used by the administrator application. This asks the admin- 
istrator to identify the name and path of the schema file used 
by the DSA. The schema file is used to obtain object classes 
and attribute lists. 

The administrator also has the ability to customize the 
appearance of the display of directory information. The 
administrator may set, inter alia, the background color, the 
font, the font color, the font size, and the page layout. 
Further, the administrator may use graphics, such as the 
organizational logo, on the page. Since directory informa- 
tion is placed into dynamically created HTML documents 
and displayed in a Web Browser, the administrator may 
control the page layout. All standard HTML tags may be 
used in these documents. By writing HTML, the adminis- 
trator may control the presentation and flow of the document 
and accordingly the directory information. 

Access to the directory information may also be con- 
trolled by the administrator. For example, an administrator 
may desire to allow Web browsers to access employee 
names, but may not wish for these Web browsers to have 
access to employee home telephone numbers or addresses. 
The administrator may choose what information from the 
directory that is displayed in the Web Browser. The admin- 
istrator does this by including or excluding the appropriate 
VAL tags in the document. 

In another embodiment, this access list may be based on 
an organization's hierarchy, providing full directory infor- 
mation access to senior members, and lesser directory infor- 
mation access to lower-ranking members. 

Other embodiments and uses of the invention will be 
apparent to those skilled in the art from consideration of the 
specification and practice of the invention disclosed herein. 
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The specification should be considered exemplary only, with 
the true scope and spirit of the invention indicated by the 
following claims. 
Wc claim: 

1. A system for creating a search form for accessing 
directory information, said system comprising: 

a server for receiving a directory request, wherein said 
directory request comprises said search form; 

a request processor in communication with said server, 
wherein said request processor responds to said direc- 
tory request; 

a server control and configuration system in communica- 
tion with said server for configuring said search form; 
and 

an administrative interface in communication with said 
server control and configuration system, wherein said 
administrative interface comprises: 

a directory information display customizer that enables 
the customization of, at least one of: background color, 
font type, font color, font size, page layout, and 
graphics, for displayed directory information; and 

a directory information access controller that enables 
control over the level of access to said directory infor- 
mation. 

2. The system of claim 1, wherein said server control and 
configuration system comprises means for creating an 
LDAP search string. 

3. The system of claim 1, further comprising a template 
file for controlling the publication of a response to said 
directory request. 

4. A system for creating a search form for accessing 
directory information, said system comprising: 

a gateway for receiving and responding to a directory 
request, wherein said directory request comprises said 
search form; 

a server control and configuration system in communica- 
tion with said gateway for configuring said search 
form; and 

an administrative interface in communication with said 
server control and configuration system, wherein said 
administrative interface comprises: 
a directory information display customizer that enables 
the customization of, at least one of: background 
color, font type, font color, font size, page layout, 
and graphics, for displayed directory information; 
and 

a directory information access controller that enables 
control over the level of access to said directory 
information. 

5. The system of claim 4, wherein said search form 
comprises a search format and an input section, wherein said 
input section allows a user to input search data. 

6. The system of claim 5, wherein said gateway creates an 
LDAP search string from said search format and said search 
data. 

7. A method for creating a search form for accessing 
directory information, said method comprising: 

determining an attribute to search; 
creating a search format; 

creating an input section, wherein said input section 
allows a user to enter search data and said input section 
is associated with a placeholder, wherein said place- 
holder has an associated index value and said associ- 
ated index value is related to the order of said place- 
holder appearance; 
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creating a search request based on said search format and 

said search data; 
wherein said step of creating a search request comprises 

replacing said place holder with said search data; and 
creating an action string for submitting said search 

request. 

8. The method of claim 7, further comprising the step of 
creating a template file, wherein said template file controls 
publication of a response to said search request. 

9. The method of claim 7, wherein said search format is 
an LDAP search filter. 

10. The method of claim 7, wherein said input section 
comprises an edit box. 

11. The method of claim 7, wherein said input section is 
associated with a placeholder. 

12. A system for creating a search form for accessing 
directory information, said system comprising: 

server means that receives a directory request, wherein the 

directory request comprises the search form; 
request processor means in communication with the 

server means, wherein the request processor means 

responds to the directory request; 
server control and configuration means in communication 

with the server means for configuring the search form; 

and 

administrative interface means in communication with the 
server control and configuration means wherein said 
administrative interface means comprises: 
directory information display customizer means that 
enable the customization of, at least one of: back- 
gound color, font type, font color, font size, page 
layout, and graphics, for displayed directory infor- 
mation; and 

directory information access controller means that 
enable control over the level of access to said direc- 
tory information. 
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13. The system of claim 12, wherein the server control 
and configuration means comprises LDAP search string 
creation means. 

14. The system of claim 12, further comprising template 
file means for controlling the publication of a response to the 
directory request, 

15. A processor readable medium containing processor 
readable code that enables the creation of a search form for 
accessing directory information, said processor readable 
medium comprising: 

search format creation code that creates a search format 
that enables the ability to search for an attribute; 

input section creation code that enables the creation of an 
input section, wherein said input section allows a user 
to enter search data and said input section is associated 
with a placeholder, wherein said placeholder has an 
associated index value and said associated index value 
is related to the order of said placeholder appearance; 

search request creation code that enables the creation of a 
search request based on said search format and said 
search data; 

wherein said search request creation code creates a search 
request that comprises replacing said placeholder with 
said search data; and 

action string creation code that enables the creation of an 
action string for submitting said search request. 

16. The processor readable medium of claim 15, further 
comprising: 

template file creation code that enables the creation of a 
template file, wherein said template file controls pub- 
lication of a response to said search request. 

17. The processor readable medium of claim 15, further 
comprising: 

automatic formatting code that enables the automatic 
formatting of a result of said search request. 
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